<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta charset="UTF-8"/>
  <meta name="viewport" content="width=device-width, initial-scale=1"/>
  <title>b(1) build2 0.17.0</title>

  <style type="text/css">
/* file      : common.css
 * license   : MIT; see accompanying LICENSE file
 */

html
{
  font-family: "Helvetica Neue", Helvetica, "Segoe UI", Arial, freesans, sans-serif;
  font-weight: normal;
  font-size: 18px;
  line-height: 1.4em;
  letter-spacing: 0.01em;

  color: #292929;
}

body {margin: 0;} /* There is non-0 default margin for body. */

/* See notes on what's going on here. */
body {min-width: 17em;}
@media only screen and (min-width: 360px)
{
  body {min-width: 19em;}
}

/*
 * Header (optional).
 */

#header-bar
{
  width: 100%;

  background: rgba(0, 0, 0, 0.04);
  border-bottom: 1px solid rgba(0, 0, 0, 0.2);

  padding: .4em 0 .42em 0;
  margin: 0 0 1.4em 0;
}

#header
{
  /* Same as in #content. */
  max-width: 41em;
  margin: 0 auto 0 auto;
  padding: 0 .4em 0 .4em;

  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box;

  width: 100%;
  display: table;
  border: none;
  border-collapse: collapse;
}

#header-logo, #header-menu
{
  display: table-cell;
  border: none;
  padding: 0;
  vertical-align: middle;
}

#header-logo {text-align: left;}
#header-menu {text-align: right;}

/* These overlap with #header's margin because of border collapsing. */
#header-logo {padding-left: .4em;}
#header-menu {padding-right: .4em;}

#header-logo a
{
  color: #000;
  text-decoration: none;
  outline: none;
}
#header-logo a:visited {color: #000;}
#header-logo a:hover, #header-logo a:active {color: #000;}

#header-menu a
{
  font-size: 0.889em;
  line-height: 1.4em;
  text-align: right;
  margin-left: 1.2em;
  white-space: nowrap;
  letter-spacing: 0;
}

#header-menu a
{
  color: #000;
  outline: none;
}
#header-menu a:visited {color: #000;}
#header-menu a:hover, #header-menu a:active
{
  color: #3870c0;
  text-decoration: none;
}

/* Flexbox-based improvements though the above works reasonably well. */
#header-menu-body
{
  width: 100%;

  display: -webkit-inline-flex;
  display: inline-flex;

  -webkit-flex-flow: row wrap;
  flex-flow: row wrap;

  -webkit-justify-content: flex-end;
  justify-content: flex-end;
}

/* Whether we want it (and at which point) depends on the size of the menu. */
/*
@media only screen and (max-width: 567px)
{
  #header-menu-body
  {
    -webkit-flex-direction: column;
    flex-direction: column;
  }
}
*/

/*
 * Content.
 */

#content
{
  max-width: 41em;
  margin: 0 auto 0 auto;
  padding: 0 .4em 0 .4em; /* Space between text and browser frame. */

  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box;
}

/*
 * Footer (optional).
 */

#footer
{
  color: #767676;
  font-size: 0.7223em;
  line-height: 1.3em;
  margin: 2.2em 0 1em 0;
  text-align: center;
}

#footer a
{
  color: #767676;
  text-decoration: underline;
}
#footer a:visited {color: #767676;}
#footer a:hover, #footer a:active {color: #3870c0;}

/* Screen size indicator in the footer. The before/after content is in case
   we don't have any content in the footer. Margin is to actually see the
   border separate from the browser frame. */

/*
#footer:before {content: "\A0";}
#footer:after {content: "\A0";}

#footer
{
  border-left: 1px solid;
  border-right: 1px solid;
  margin-left: 1px;
  margin-right: 1px;
}

@media only screen and (max-width: 359px)
{
  #footer {border-color: red;}
}

@media only screen and (min-width: 360px) and (max-width: 567px)
{
  #footer {border-color: orange;}
}

@media only screen and (min-width: 568px) and (max-width: 1023px)
{
  #footer {border-color: blue;}
}

@media only screen and (min-width: 1024px)
{
  #footer {border-color: green;}
}
*/

/*
 * Common elements.
 */

p, li, dd {text-align: justify;}
.code {text-align: left;} /* Manually aligned. */
pre {text-align: left;}   /* If it is inside li/dd. */

/* Notes. */

.note
{
  color: #606060;
}

div.note
{
  margin: 2em 0 2em 0; /* The same top/bottom margings as pre box. */

  padding-left: 0.5em;
  border: 0.25em;
  border-left-style: solid;
  border-color: #808080;

  page-break-inside: avoid;
}

div.note :first-child {margin-top:    0;}
div.note :last-child  {margin-bottom: 0;}

span.note::before {content: "[Note: "}
span.note::after  {content: "]"}

/* Links. */
a
{
  color: #3870c0;
  /*color: #4078c0;*/
  text-decoration: none;
}

a:hover, a:active
{
/*color: #006fbf;*/
/*color: #0087e7;*/
  text-decoration: underline;
}

a:visited
{
/*color: #003388;*/
  color: #00409c;
}

/* Standard paragraph. */

p, pre {margin: 1em 0 1em 0;}

/* Standard lists. */
ul, ol, dl {margin: 1em 0 1em 0;}
ul li, ol li {margin: 0 0 .4em 0;}
ul li {list-style-type: circle;}
dl dt {margin: 0 0 0 0;}
dl dd {margin: 0 0 .6em 1.8em;}

code, pre
{
  font-family: Consolas, "Liberation Mono", Menlo, Courier, monospace;
  font-size: 0.92em;
  letter-spacing: 0;
}

pre {white-space: pre-wrap;}
@media only screen and (max-width: 567px)
{
  pre {word-break: break-all;}
}

/* Use page rather than system font settings. */
input
{
  font-family: inherit;
  font-weight: inherit;
  font-size:   inherit;
  line-height: inherit;
}

/* file      : pre-box.css
 * license   : MIT; see accompanying LICENSE file
 */

/* Note: see also p-code-box.css. */

pre
{
  background-color: rgba(0, 0, 0, 0.05);
  border-radius: 0.2em;
  padding: .8em .4em .8em .4em;
  margin: 2em -.4em 2em -.4em; /* Use margins of #content. */
}

/* file      : man.css
 * license   : MIT; see accompanying LICENSE file
 */

/* Bases:
 *
 * common.css
 * pre-box.css
 *
 */

#content
{
  max-width: 42.1em;
  padding-left: 1.5em; /* Reserve for the heading. */
}

h1
{
  font-weight: normal;
  font-size: 1.58em;
  line-height: 1.4em;
  margin: 1.6em 0 .6em -.88em;
}

/* Definition list for options. */
dl.options dt {margin: 1em 0 0 0;}
dl.options dd {margin: .1em 0 0 4.5em;}

/* Make lists inside option descriptions a tad smaller. */
dl.options dd ul, dl.options dd ol, dl.options dd dl
{
  font-size: 0.889em;
  line-height: 1.4em;
}

  </style>

</head>
<body>
<div id="content">

  <h1>NAME</h1>

  <p><b><code>b</code></b> &#8211; build system driver</p>
  <h1>SYNOPSIS</h1>

  <p class="code"><code><b>b --help</b>
  <br/>
  <b>b --version</b>
  <br/>
  <b>b</b> [<i>options</i>] [<i>variables</i>] [<i>buildspec</i>]</code></p>

  <p class="code"><code><i>buildspec</i> =
  <i>meta-operation</i><b>(</b><i>operation</i><b>(</b><i>target</i>...[<b>,</b><i>parameters</i>]<b>)</b>...<b>)</b>...</code></p>

  <h1>DESCRIPTION</h1>

  <p>The <code><b>build2</b></code> build system driver executes a set of
  meta-operations on operations on targets according to the build
  specification, or <i>buildspec</i> for short.  This process can be
  controlled by specifying driver <code><i>options</i></code> and build system
  <code><i>variables</i></code>.</p>

  <p>Note that <code><i>options</i></code>, <code><i>variables</i></code>, and
  <code><i>buildspec</i></code> fragments can be specified in any order. To
  avoid treating an argument that starts with <code><b>'-'</b></code> as an
  option, add the <code><b>'--'</b></code> separator. To avoid treating an
  argument that contains <code><b>'='</b></code> as a variable, add the second
  <code><b>'--'</b></code> separator.</p>

  <p>All components in the buildspec can be omitted. If
  <code><i>meta-operation</i></code> is omitted, then it defaults to
  <code><b>perform</b></code>. If <code><i>operation</i></code> is omitted,
  then it defaults to the default operation for this meta-operation. For
  <code><b>perform</b></code> it is <code><b>update</b></code>. Finally, if
  <code><i>target</i></code> is omitted, then it defaults to the current
  working directory. A meta-operation on operation is called an <i>action</i>.
  Some operations and meta-operations may take additional
  <code><i>parameters</i></code>. For example:</p>

  <pre>$ b                       # perform(update(./))
$ b foo/                  # perform(update(foo/))
$ b foo/ bar/             # perform(update(foo/ bar/))
$ b update                # perform(update(./))
$ b 'clean(../)'          # perform(clean(../))
$ b perform               # perform(update(./))
$ b configure             # configure(?(./))
$ b 'configure(../)'      # configure(?(../))
$ b clean update          # perform(clean(./) update(./))
$ b configure update      # configure(?(./)) perform(update(./))
$ b 'create(conf/, cxx)'  # create(?(conf/), cxx)</pre>

  <p>Notice the question mark used to show the (imaginary) default operation
  for the <code><b>configure</b></code> meta-operation. For
  <code><b>configure</b></code> the default operation is "all operations".
  That is, it will configure all the operations for the specified target.</p>

  <p>You can also "generate" multiple operations for the same set of targets.
  Compare:</p>

  <pre>$ b 'clean(foo/ bar/)' 'update(foo/ bar/)'
$ b '{clean update}(foo/ bar/)'</pre>

  <p>Some more useful buildspec examples:</p>

  <pre>$ b '{clean update}(...)'        # rebuild
$ b '{clean update clean}(...)'  # make sure builds
$ b '{clean test clean}(...)'    # make sure passes tests
$ b '{clean disfigure}(...)'     # similar to distclean</pre>

  <p>In POSIX shells parenthesis are special characters and must be quoted
  when used in a buildspec. Besides being an inconvenience in itself, quoting
  also inhibits path auto-completion. To help with this situation a shortcut
  syntax is available for executing a single operation or meta-operation, for
  example:</p>

  <pre>$ b clean: foo/ bar/                # clean(foo/ bar/)
$ b configure: src/@out/            # configure(src/@out/)
$ b create: conf/, cxx              # create(conf/, cxx)
$ b configure: config.cxx=g++ src/  # configure(src/) config.cxx=g++</pre>

  <p>To activate the shortcut syntax the first buildspec argument must start
  with an operation or meta-operation name and end with a colon
  (<code><b>:</b></code>). To transform the shortcut syntax to the normal
  buildspec syntax the colon is replaced with the opening parenthesis
  ('<code><b>(</b></code>'), the rest of the buildspec arguments are treated
  as is, and the final closing parenthesis ('<code><b>)</b></code>') is
  added.</p>

  <p>For each <code><i>target</i></code> the driver expects to find
  <code><b>buildfile</b></code> either in the target's directory or, if the
  directory is part of the <code><b>out</b></code> tree
  (<code><b>out_base</b></code>), in the corresponding <code><b>src</b></code>
  directory (<code><b>src_base</b></code>).</p>

  <p>For example, assuming <code><b>foo/</b></code> is the source directory of
  a project:</p>

  <pre>$ b foo/              # out_base=src_base=foo/
$ b foo-out/          # out_base=foo-out/ src_base=foo/
$ b foo-out/exe{foo}  # out_base=foo-out/ src_base=foo/</pre>

  <p>An exception to this requirement is a directory target in which case,
  provided the directory has subdirectories, an <i>implied</i>
  <code><b>buildfile</b></code> with the following content is assumed:</p>

  <pre># Implied directory buildfile: build all subdirectories.
#
./: */</pre>

  <p>In the above example, we assumed that the build system driver was able to
  determine the association between <code><b>out_base</b></code> and
  <code><b>src_base</b></code>. In case <code><b>src_base</b></code> and
  <code><b>out_base</b></code> are not the same directory, this is achieved in
  one of two ways: the <code><b>config</b></code> module (which implements the
  <code><b>configure</b></code>, <code><b>disfigure</b></code>, and
  <code><b>create</b></code> meta-operations) saves this association as part
  of the configuration process. If, however, the association hasn't been
  saved, then we have to specify <code><b>src_base</b></code> explicitly using
  the following extended <code><i>target</i></code> syntax:</p>

  <p class="code"><code><i>src-base</i>/@<i>target</i></code></p>

  <p>Continuing with the previous example:</p>

  <pre>$ b foo/@foo-out/exe{foo}  # out_base=foo-out/ src_base=foo/</pre>

  <p>Normally, you would need to specify <code><b>src_base</b></code>
  explicitly only once, during configuration. For example, a typical usage
  would be:</p>

  <pre>$ b configure: foo/@foo-out/  # src_base is saved
$ b foo-out/                  # no need to specify src_base
$ b clean: foo-out/exe{foo}   # no need to specify src_base</pre>

  <p>Besides in and out of source builds, <code><b>build2</b></code> also
  supports configuring a project's source directory as <i>forwarded</i> to an
  out of source build. With such a forwarded configuration in place, if we run
  the build system driver from the source directory, it will automatically
  build in the output directory and <i>backlink</i> (using symlinks or another
  suitable mechanism) certain "interesting" targets (executables,
  documentation, etc) to the source directory for easy access. Continuing with
  the previous example:</p>

  <pre>$ b configure: foo/@foo-out/,forward  # foo/ forwarded to foo-out/
$ cd foo/
$ b                                   # build in foo-out/
$ ./foo                               # symlink to foo-out/foo</pre>

  <p>The ability to specify <code><b>build2</b></code> variables as part of
  the command line is normally used to pass configuration values, for
  example:</p>

  <pre>$ b config.cxx=clang++ config.cxx.coptions=-O3</pre>

  <p>Similar to buildspec, POSIX shells often inhibit path auto-completion on
  the right hand side of a variable assignment. To help with this situation
  the assignment can be broken down into three separate command line
  arguments, for example:</p>

  <pre>$ b config.import.libhello = ../libhello/</pre>

  <p>The build system has the following built-in and pre-defined
  meta-operations:</p>

  <dl>
  <dt><code><b>perform</b></code></dt>
  <dd>Perform an operation.</dd>

  <dt><code><b>configure</b></code></dt>
  <dd>Configure all operations supported by a project and save the result in
  the project's <code><b>build/config.build</b></code> file. Implemented by
  the <code><b>config</b></code> module. For example:

  <pre>$ b configure                      \
    config.cxx=clang++             \
    config.cxx.coptions=-O3        \
    config.install.root=/usr/local \
    config.install.root.sudo=sudo</pre>

  <p>Use the <code><b>forward</b></code> parameter to instead configure a
  source directory as forwarded to an out of source build. For example:</p>

  <pre>$ b configure: src/@out/,forward</pre></dd>

  <dt><code><b>disfigure</b></code></dt>
  <dd>Disfigure all operations supported by a project and remove the project's
  <code><b>build/config.build</b></code> file. Implemented by the
  <code><b>config</b></code> module.

  <p>Use the <code><b>forward</b></code> parameter to instead disfigure
  forwarding of a source directory to an out of source build. For example:</p>

  <pre>$ b disfigure: src/,forward</pre></dd>

  <dt><code><b>create</b></code></dt>
  <dd>Create and configure a <i>configuration</i> project. Implemented by the
  <code><b>config</b></code> module.

  <p>Normally a <code><b>build2</b></code> project is created manually by
  writing the <code><b>bootstrap.build</b></code> and
  <code><b>config.build</b></code> files, adding source files, and so on.
  However, a special kind of project, which we call <i>configuration</i>, is
  often useful. Such a project doesn't have any source files of its own.
  Instead, it serves as an amalgamation for building other projects as part of
  it. Doing it this way has two major benefits: sub-projects automatically
  resolve their imports to other projects in the amalgamation and sub-projects
  inherits their configuration from the amalgamation (which means if we want
  to change something, we only need to do it in one place).</p>

  <p>As an example, let's assume we have two C++ projects: the
  <code><b>libhello</b></code> library in <code><b>libhello/</b></code> and
  the <code><b>hello</b></code> executable that imports it in
  <code><b>hello/</b></code>. And we want to build <code><b>hello</b></code>
  with <code><b>clang++</b></code>.</p>

  <p>One way to do it would be to configure and build each project in its own
  directory, for example:</p>

  <pre>$ b configure: libhello/@libhello-clang/ config.cxx=clang++
$ b configure: hello/@hello-clang/ config.cxx=clang++ \
    config.import.libhello=libhello-clang/</pre>

  <p>The two drawbacks, as mentioned above, are the need to explicitly resolve
  the import and having to make changes in multiple places should, for
  example, we want to switch from <code><b>clang++</b></code> to
  <code><b>g++</b></code>.</p>

  <p>We can, however, achieve the same end result but without any of the
  drawbacks using the configuration project:</p>

  <pre>$ b create: clang/,cxx config.cxx=clang++  # Creates clang/.
$ b configure: libhello/@clang/libhello/
$ b configure: hello/@clang/hello/</pre>

  <p>The targets passed to the <code><b>create</b></code> meta-operation must
  be directories which should either not exist or be empty. For each such
  directory <code><b>create</b></code> first initializes a project as
  described below and then configures it by executing the
  <code><b>configure</b></code> meta-operation.</p>

  <p>The first optional parameter to <code><b>create</b></code> is the list of
  modules to load in <code><b>root.build</b></code>. By default,
  <code><b>create</b></code> appends <code><b>.config</b></code> to the names
  of these modules so that only their configurations are loaded. You can
  override this behavior by specifying the period (<code><b>.</b></code>) 
  after the module name. You can also instruct <code><b>create</b></code> to
  use the optional module load by prefixing the module name with the question
  mark (<code><b>?</b></code>).</p>

  <p>The second optional parameter is the list of modules to load in
  <code><b>bootstrap.build</b></code>. If not specified, then the
  <code><b>test</b></code>, <code><b>dist</b></code>, and
  <code><b>install</b></code> modules are loaded by default. The
  <code><b>config</b></code> module is always loaded first.</p>

  <p>Besides creating project's <code><b>bootstrap.build</b></code> and
  <code><b>root.build</b></code>, <code><b>create</b></code> also writes the
  root <code><b>buildfile</b></code> with the following contents:</p>

  <pre>./: {*/ -build/}</pre>

  <p>If used, this <code><b>buildfile</b></code> will build all the
  sub-projects currently present in the configuration.</p></dd>

  <dt><code><b>dist</b></code></dt>
  <dd>Prepare a distribution containing all files necessary to perform all
  operations in a project. Implemented by the <code><b>dist</b></code>
  module.</dd>

  <dt><code><b>info</b></code></dt>
  <dd>Print basic information (name, version, source and output directories,
  etc) about one or more projects to <code><b>stdout</b></code>, separating
  multiple projects with a blank line. Each project is identified by its root
  directory target. For example (some output is omitted):

  <pre>$ b info: libfoo/ libbar/
project: libfoo
version: 1.0.0
src_root: /tmp/libfoo
out_root: /tmp/libfoo
subprojects: @tests

project: libbar
version: 2.0.0
src_root: /tmp/libbar
out_root: /tmp/libbar-out
subprojects: @tests</pre>

  <p>To omit discovering and printing subprojects information, use the
  <code><b>no_subprojects</b></code> parameter, for example:</p>

  <pre>$ b info: libfoo/,no_subprojects</pre>

  <p>To instead print this information in the JSON format, use the
  <code><b>json</b></code> parameter, for example:</p>

  <pre>$ b info: libfoo/,json</pre>

  <p>In this case the output is a JSON array of objects which are the
  serialized representation of the following C++ <code><b>struct</b></code>
  <code><b>project_info</b></code>:</p>

  <pre>struct subproject
{
  string           path;
  optional&lt;string> name;
};

struct project_info
{
  optional&lt;string>   project;
  optional&lt;string>   version;
  optional&lt;string>   summary;
  optional&lt;string>   url;
  string             src_root;
  string             out_root;
  optional&lt;string>   amalgamation;
  vector&lt;subproject> subprojects;
  vector&lt;string>     operations;
  vector&lt;string>     meta_operations;
  vector&lt;string>     modules;
};</pre>

  <p>For example:</p>

  <pre>[
  {
    "project": "libfoo",
    "version": "1.0.0",
    "summary": "libfoo C++ library",
    "src_root": "/tmp/libfoo",
    "out_root": "/tmp/gcc-debug/libfoo",
    "amalgamation": "..",
    "subprojects": [
      {
        "path": "tests"
      }
    ],
    "operations": [
      "update",
      "clean",
      "test",
      "update-for-test",
      "install",
      "uninstall",
      "update-for-install"
    ],
    "meta-operations": [
      "perform",
      "configure",
      "disfigure",
      "dist",
      "info"
    ],
    "modules": [
      "version",
      "config",
      "test",
      "install",
      "dist"
    ]
  }
]</pre>

  <p>See the JSON OUTPUT section below for details on the overall properties
  of this format and the semantics of the <code><b>struct</b></code>
  serialization.</p></dd>
  </dl>

  <p>The build system has the following built-in and pre-defined
  operations:</p>

  <dl>
  <dt><code><b>update</b></code></dt>
  <dd>Update a target.</dd>

  <dt><code><b>clean</b></code></dt>
  <dd>Clean a target.</dd>

  <dt><code><b>test</b></code></dt>
  <dd>Test a target. Performs <code><b>update</b></code> as a pre-operation.
  Implemented by the <code><b>test</b></code> module.</dd>

  <dt><code><b>update-for-test</b></code></dt>
  <dd>Update a target for testing. This operation is equivalent to the
  <code><b>update</b></code> pre-operation as executed by the
  <code><b>test</b></code> operation and can be used to only update what is
  necessary for testing. Implemented by the <code><b>test</b></code>
  module.</dd>

  <dt><code><b>install</b></code></dt>
  <dd>Install a target. Performs <code><b>update</b></code> as a
  pre-operation. Implemented by the <code><b>install</b></code> module.</dd>

  <dt><code><b>uninstall</b></code></dt>
  <dd>Uninstall a target. Performs <code><b>update</b></code> as a
  pre-operation. Implemented by the <code><b>install</b></code> module.</dd>

  <dt><code><b>update-for-install</b></code></dt>
  <dd>Update a target for installation. This operation is equivalent to the
  <code><b>update</b></code> pre-operation as executed by the
  <code><b>install</b></code> operation and can be used to only update what is
  necessary for installation. Implemented by the <code><b>install</b></code>
  module.</dd>
  </dl>

  <p>Note that buildspec and command line variable values are treated as
  <code><b>buildfile</b></code> fragments and so can use quoting and escaping
  as well as contain variable expansions and evaluation contexts. However, to
  be more usable on various platforms, escaping in these two situations is
  limited to the <i>effective sequences</i> of <code><b>\'</b></code>,
  <code><b>\"</b></code>, <code><b>\\</b></code>, <code><b>\$</b></code>, and
  <code><b>\(</b></code> with all other sequences interpreted as is. Together
  with double-quoting this is sufficient to represent any value. For
  example:</p>

  <pre>$ b config.install.root=c:\projects\install
$ b "config.install.root='c:\Program Files\test\'"
$ b 'config.cxx.poptions=-DFOO_STR="foo"'</pre>

  <h1 id="options">OPTIONS</h1>

  <dl class="options">
    <dt><code><b>-v</b></code></dt>
    <dd>Print actual commands being executed. This options is equivalent to
    <code><b>--verbose 2</b></code>.</dd>

    <dt><code><b>-V</b></code></dt>
    <dd>Print all underlying commands being executed. This options is
    equivalent to <code><b>--verbose 3</b></code>.</dd>

    <dt><code><b>--quiet</b></code>|<code><b>-q</b></code></dt>
    <dd>Run quietly, only printing error messages in most contexts. In certain
    contexts (for example, while updating build system modules) this verbosity
    level may be ignored. Use <code><b>--silent</b></code> to run quietly in
    all contexts. This option is equivalent to <code><b>--verbose
    0</b></code>.</dd>

    <dt><code><b>--silent</b></code></dt>
    <dd>Run quietly, only printing error messages in all contexts.</dd>

    <dt><code><b>--verbose</b></code> <code><i>level</i></code></dt>
    <dd>Set the diagnostics verbosity to <code><i>level</i></code> between 0
    and 6. Level 0 disables any non-error messages (but see the difference
    between <code><b>--quiet</b></code> and <code><b>--silent</b></code>)
    while level 6 produces lots of information, with level 1 being the
    default. The following additional types of diagnostics are produced at
    each level:

    <ol>
    <li>High-level information messages.</li>

    <li>Essential underlying commands being executed.</li>

    <li>All underlying commands being executed.</li>

    <li>Information that could be helpful to the user.</li>

    <li>Information that could be helpful to the developer.</li>

    <li>Even more detailed information.</li>
    </ol></dd>

    <dt><code><b>--stat</b></code></dt>
    <dd>Display build statistics.</dd>

    <dt><code><b>--progress</b></code></dt>
    <dd>Display build progress. If printing to a terminal the progress is
    displayed by default for low verbosity levels. Use
    <code><b>--no-progress</b></code> to suppress.</dd>

    <dt><code><b>--no-progress</b></code></dt>
    <dd>Don't display build progress.</dd>

    <dt><code><b>--diag-color</b></code></dt>
    <dd>Use color in diagnostics. If printing to a terminal the color is used
    by default provided the terminal is not dumb. Use
    <code><b>--no-diag-color</b></code> to suppress.

    <p>This option affects the diagnostics printed by the build system itself.
    Some rules may also choose to propagate its value to tools (such as
    compilers) that they invoke.</p></dd>

    <dt><code><b>--no-diag-color</b></code></dt>
    <dd>Don't use color in diagnostics.</dd>

    <dt><code><b>--jobs</b></code>|<code><b>-j</b></code> <code><i>num</i></code></dt>
    <dd>Number of active jobs to perform in parallel. This includes both the
    number of active threads inside the build system as well as the number of
    external commands (compilers, linkers, etc) started but not yet finished.
    If this option is not specified or specified with the
    <code><b>0</b></code> value, then the number of available hardware threads
    is used.</dd>

    <dt><code><b>--max-jobs</b></code>|<code><b>-J</b></code> <code><i>num</i></code></dt>
    <dd>Maximum number of jobs (threads) to create. The default is 8x the
    number of active jobs (<code><b>--jobs|j</b></code>) on 32-bit
    architectures and 32x on 64-bit. See the build system scheduler
    implementation for details.</dd>

    <dt><code><b>--queue-depth</b></code>|<code><b>-Q</b></code> <code><i>num</i></code></dt>
    <dd>The queue depth as a multiplier over the number of active jobs.
    Normally we want a deeper queue if the jobs take long (for example,
    compilation) and shorter if they are quick (for example, simple tests).
    The default is 4. See the build system scheduler implementation for
    details.</dd>

    <dt><code><b>--file-cache</b></code> <code><i>impl</i></code></dt>
    <dd>File cache implementation to use for intermediate build results. Valid
    values are <code><b>noop</b></code> (no caching or compression) and
    <code><b>sync-lz4</b></code> (no caching with synchronous LZ4 on-disk
    compression). If this option is not specified, then a suitable default
    implementation is used (currently <code><b>sync-lz4</b></code>).</dd>

    <dt><code><b>--max-stack</b></code> <code><i>num</i></code></dt>
    <dd>The maximum stack size in KBytes to allow for newly created threads.
    For <i>pthreads</i>-based systems the driver queries the stack size of the
    main thread and uses the same size for creating additional threads. This
    allows adjusting the stack size using familiar mechanisms, such as
    <code><b>ulimit</b></code>. Sometimes, however, the stack size of the main
    thread is excessively large. As a result, the driver checks if it is
    greater than a predefined limit (64MB on 64-bit systems and 32MB on 32-bit
    ones) and caps it to a more sensible value (8MB) if that's the case. This
    option allows you to override this check with the special zero value
    indicating that the main thread stack size should be used as is.</dd>

    <dt><code><b>--serial-stop</b></code>|<code><b>-s</b></code></dt>
    <dd>Run serially and stop at the first error. This mode is useful to
    investigate build failures that are caused by build system errors rather
    than compilation errors. Note that if you don't want to keep going but
    still want parallel execution, add <code><b>--jobs|-j</b></code> (for
    example <code><b>-j&#160;0</b></code> for default concurrency). Note also
    that during serial execution there is no diagnostics buffering and child
    process' <code><b>stderr</b></code> is a terminal (unless redirected; see
    <code><b>--no-diag-buffer</b></code> for details).</dd>

    <dt><code><b>--dry-run</b></code>|<code><b>-n</b></code></dt>
    <dd>Print commands without actually executing them. Note that commands
    that are required to create an accurate build state will still be executed
    and the extracted auxiliary dependency information saved. In other words,
    this is not the <i>"don't touch the filesystem"</i> mode but rather <i>"do
    minimum amount of work to show what needs to be done"</i>. Note also that
    only the <code><b>perform</b></code> meta-operation supports this
    mode.</dd>

    <dt><code><b>--no-diag-buffer</b></code></dt>
    <dd>Do not buffer diagnostics from child processes. By default, unless
    running serially, such diagnostics is buffered and printed all at once
    after each child exits in order to prevent interleaving. However, this can
    have side-effects since the child process' <code><b>stderr</b></code> is
    no longer a terminal. Most notably, the use of color in diagnostics may be
    disabled by some programs. On the other hand, depending on the platform
    and programs invoked, the interleaving diagnostics may not break lines and
    thus could be tolerable.</dd>

    <dt><code><b>--match-only</b></code></dt>
    <dd>Match the rules without executing the operation. This mode is
    primarily useful for profiling and dumping the build system state.</dd>

    <dt><code><b>--load-only</b></code></dt>
    <dd>Match the rules only to <code><b>alias{}</b></code> targets ignoring
    other targets and without executing the operation. In particular, this has
    the effect of loading all the subdirectory <code><b>buildfiles</b></code>
    that are not explicitly included. Note that this option can only be used
    with the <code><b>perform(update)</b></code> action on an
    <code><b>alias{}</b></code> target, usually
    <code><b>dir{}</b></code>.</dd>

    <dt><code><b>--no-external-modules</b></code></dt>
    <dd>Don't load external modules during project bootstrap. Note that this
    option can only be used with meta-operations that do not load the
    project's <code><b>buildfiles</b></code>, such as
    <code><b>info</b></code>.</dd>

    <dt><code><b>--structured-result</b></code> <code><i>fmt</i></code></dt>
    <dd>Write the result of execution in a structured form. In this mode,
    instead of printing to <code><b>stderr</b></code> diagnostics messages
    about the outcome of executing actions on targets, the driver writes to
    <code><b>stdout</b></code> a machine-readable result description in the
    specified format. Valid values for this option are
    <code><b>lines</b></code> and <code><b>json</b></code>. Note that
    currently only the <code><b>perform</b></code> meta-operation supports the
    structured result output.

    <p>If the output format is <code><b>lines</b></code>, then the result is
    written one line per the buildspec action/target pair. Each line has the
    following form:</p>

    <p class="code"><code><i>state</i> <i>meta-operation</i> <i>operation</i>
    <i>target</i></code></p>

    <p>Where <code><i>state</i></code> can be one of
    <code><b>unchanged</b></code>, <code><b>changed</b></code>, or
    <code><b>failed</b></code>. If the action is a pre or post operation, then
    the outer operation is specified in parenthesis. For example:</p>

    <pre>unchanged perform update(test) /tmp/hello/hello/exe{hello}
changed perform test /tmp/hello/hello/exe{hello}</pre>

    <p>If the output format is <code><b>json</b></code>, then the output is a
    JSON array of objects which are the serialized representation of the
    following C++ <code><b>struct</b></code>
    <code><b>target_action_result</b></code>:</p>

    <pre>struct target_action_result
{
  string           target;
  string           display_target;
  string           target_type;
  optional&lt;string> target_path;
  string           meta_operation;
  string           operation;
  optional&lt;string> outer_operation;
  string           state;
};</pre>

    <p>For example:</p>

    <pre>[
  {
    "target": "/tmp/hello/hello/exe{hello.}",
    "display_target": "/tmp/hello/hello/exe{hello}",
    "target_type": "exe",
    "target_path": "/tmp/hello/hello/hello",
    "meta_operation": "perform",
    "operation": "update",
    "outer_operation": "test",
    "state": "unchanged"
  },
  {
    "target": "/tmp/hello/hello/exe{hello.}",
    "display_target": "/tmp/hello/hello/exe{hello}",
    "target_type": "exe",
    "target_path": "/tmp/hello/hello/hello",
    "meta_operation": "perform",
    "operation": "test",
    "state": "changed"
  }
]</pre>

    <p>See the JSON OUTPUT section below for details on the overall properties
    of this format and the semantics of the <code><b>struct</b></code>
    serialization.</p>

    <p>The <code><b>target</b></code> member is the target name that is
    qualified with the extension (if applicable) and, if required, is quoted
    so that it can be passed back to the build system driver on the command
    line. The <code><b>display_target</b></code> member is the unqualified and
    unquoted "display" target name, the same as in the
    <code><b>lines</b></code> format. The <code><b>target_type</b></code>
    member is the type of target.  The <code><b>target_path</b></code> member
    is an absolute path to the target if the target type is path-based or
    <code><b>dir</b></code>.</p></dd>

    <dt><code><b>--mtime-check</b></code></dt>
    <dd>Perform file modification time sanity checks. These checks can be
    helpful in diagnosing spurious rebuilds and are enabled by default on
    Windows (which is known not to guarantee monotonically increasing mtimes)
    and for the staged version of the build system on other platforms. Use
    <code><b>--no-mtime-check</b></code> to disable.</dd>

    <dt><code><b>--no-mtime-check</b></code></dt>
    <dd>Don't perform file modification time sanity checks. See
    <code><b>--mtime-check</b></code> for details.</dd>

    <dt><code><b>--dump</b></code> <code><i>phase</i></code></dt>
    <dd>Dump the build system state after the specified phase. Valid
    <code><i>phase</i></code> values are <code><b>load</b></code> (after
    loading <code><b>buildfiles</b></code>) and <code><b>match</b></code>
    (after matching rules to targets). The <code><b>match</b></code> value
    also has the <code><b>match-pre</b></code> and
    <code><b>match-post</b></code> variants to dump the state for the
    pre/post-operations (<code><b>match</b></code> dumps the main operation
    only). Repeat this option to dump the state after multiple
    phases/variants. By default the entire build state is dumped but this
    behavior can be altered with the <code><b>--dump-scope</b></code> and
    <code><b>--dump-target</b></code> options. See also the
    <code><b>--match-only</b></code> and <code><b>--load-only</b></code>
    options.</dd>

    <dt><code><b>--dump-format</b></code> <code><i>format</i></code></dt>
    <dd>Representation format and output stream to use when dumping the build
    system state. Valid values for this option are
    <code><b>buildfile</b></code> (a human-readable, Buildfile-like format
    written to <code><b>stderr</b></code>; this is the default), and
    <code><b>json-v0.1</b></code> (machine-readable, JSON-based format written
    to <code><b>stdout</b></code>). For details on the
    <code><b>buildfile</b></code> format, see <a
    href="build2-build-system-manual.xhtml#intro-diag-debug">Diagnostics and
    Debugging</a>. For details on the <code><b>json-v0.1</b></code> format,
    see the JSON OUTPUT section below (overall properties) and <a
    href="build2-build-system-manual.xhtml#json-dump">JSON Dump Format</a>
    (format specifics). Note that the JSON format is currently unstable (thus
    the temporary <code><b>-v0.1</b></code> suffix).

    <p>Note that because it's possible to end up with multiple dumps (for
    example, by specifying the <code><b>--dump-scope</b></code> and/or
    <code><b>--dump-target</b></code> options multiple times), the JSON output
    is in the "JSON Lines" form, that is, without pretty-printing and with the
    top-level JSON objects delimited by newlines. Note also that if the JSON
    dump output is combined with <code><b>--structured-result=json</b></code>,
    then the structured result is the last line.</p></dd>

    <dt><code><b>--dump-scope</b></code> <code><i>dir</i></code></dt>
    <dd>Dump the build system state for the specified scope only. Repeat this
    option to dump the state of multiple scopes.</dd>

    <dt><code><b>--dump-target</b></code> <code><i>target</i></code></dt>
    <dd>Dump the build system state for the specified target only. Repeat this
    option to dump the state of multiple targets.</dd>

    <dt><code><b>--trace-match</b></code> <code><i>target</i></code></dt>
    <dd>Trace rule matching for the specified target. This is primarily useful
    during troubleshooting. Repeat this option to trace multiple targets.</dd>

    <dt><code><b>--trace-execute</b></code> <code><i>target</i></code></dt>
    <dd>Trace rule execution for the specified target. This is primarily
    useful during troubleshooting. Repeat this option to trace multiple
    targets.</dd>

    <dt><code><b>--no-column</b></code></dt>
    <dd>Don't print column numbers in diagnostics.</dd>

    <dt><code><b>--no-line</b></code></dt>
    <dd>Don't print line and column numbers in diagnostics.</dd>

    <dt><code><b>--buildfile</b></code> <code><i>path</i></code></dt>
    <dd>The alternative file to read build information from. The default is
    <code><b>buildfile</b></code> or <code><b>build2file</b></code>, depending
    on the project's build file/directory naming scheme. If
    <code><i>path</i></code> is '<code><b>-</b></code>', then read from
    <code><b>stdin</b></code>. Note that this option only affects the files
    read as part of the buildspec processing. Specifically, it has no effect
    on the <code><b>source</b></code> and <code><b>include</b></code>
    directives. As a result, this option is primarily intended for testing
    rather than changing the build file names in real projects.</dd>

    <dt><code><b>--config-guess</b></code> <code><i>path</i></code></dt>
    <dd>The path to the <code><b>config.guess(1)</b></code> script that should
    be used to guess the host machine triplet. If this option is not
    specified, then <code><b>b</b></code> will fall back on to using the
    target it was built for as host.</dd>

    <dt><code><b>--config-sub</b></code> <code><i>path</i></code></dt>
    <dd>The path to the <code><b>config.sub(1)</b></code> script that should
    be used to canonicalize machine triplets. If this option is not specified,
    then <code><b>b</b></code> will use its built-in canonicalization support
    which should be sufficient for commonly-used platforms.</dd>

    <dt><code><b>--pager</b></code> <code><i>path</i></code></dt>
    <dd>The pager program to be used to show long text. Commonly used pager
    programs are <code><b>less</b></code> and <code><b>more</b></code>. You
    can also specify additional options that should be passed to the pager
    program with <code><b>--pager-option</b></code>. If an empty string is
    specified as the pager program, then no pager will be used. If the pager
    program is not explicitly specified, then <code><b>b</b></code> will try
    to use <code><b>less</b></code>. If it is not available, then no pager
    will be used.</dd>

    <dt><code><b>--pager-option</b></code> <code><i>opt</i></code></dt>
    <dd>Additional option to be passed to the pager program. See
    <code><b>--pager</b></code> for more information on the pager program.
    Repeat this option to specify multiple pager options.</dd>

    <dt><code><b>--options-file</b></code> <code><i>file</i></code></dt>
    <dd>Read additional options from <code><i>file</i></code>. Each option
    should appear on a separate line optionally followed by space or equal
    sign (<code><b>=</b></code>) and an option value. Empty lines and lines
    starting with <code><b>#</b></code> are ignored. Option values can be
    enclosed in double (<code><b>"</b></code>) or single
    (<code><b>'</b></code>) quotes to preserve leading and trailing
    whitespaces as well as to specify empty values. If the value itself
    contains trailing or leading quotes, enclose it with an extra pair of
    quotes, for example <code><b>'"x"'</b></code>. Non-leading and
    non-trailing quotes are interpreted as being part of the option value.

    <p>The semantics of providing options in a file is equivalent to providing
    the same set of options in the same order on the command line at the point
    where the <code><b>--options-file</b></code> option is specified except
    that the shell escaping and quoting is not required. Repeat this option to
    specify more than one options file.</p></dd>

    <dt><code><b>--default-options</b></code> <code><i>dir</i></code></dt>
    <dd>The directory to load additional default options files from.</dd>

    <dt><code><b>--no-default-options</b></code></dt>
    <dd>Don't load default options files.</dd>

    <dt><code><b>--help</b></code></dt>
    <dd>Print usage information and exit.</dd>

    <dt><code><b>--version</b></code></dt>
    <dd>Print version and exit.</dd>
  </dl>

  <h1>DEFAULT OPTIONS FILES</h1>

  <p>Instead of having a separate config file format for tool configuration,
  the <code><b>build2</b></code> toolchain uses <i>default options files</i>
  which contain the same options as what can be specified on the command line.
  The default options files are like options files that one can specify with
  <code><b>--options-file</b></code> except that they are loaded by
  default.</p>

  <p>The default options files for the build system driver are called
  <code><b>b.options</b></code> and are searched for in the
  <code><b>.build2/</b></code> subdirectory of the home directory and in the
  system directory (for example, <code><b>/etc/build2/</b></code>) if
  configured. Note that besides options these files can also contain global
  variable overrides.</p>

  <p>Once the search is complete, the files are loaded in the reverse order,
  that is, beginning from the system directory (if any), followed by the home
  directory, and finishing off with the options specified on the command line.
  In other words, the files are loaded from the more generic to the more
  specific with the command line options having the ability to override any
  values specified in the default options files.</p>

  <p>If a default options file contains
  <code><b>--no-default-options</b></code>, then the search is stopped at the
  directory containing this file and no outer files are loaded. If this option
  is specified on the command line, then none of the default options files are
  searched for or loaded.</p>

  <p>An additional directory containing default options files can be specified
  with <code><b>--default-options</b></code>. Its configuration files are
  loaded after the home directory.</p>

  <p>The order in which default options files are loaded is traced at the
  verbosity level 3 (<code><b>-V</b></code> option) or higher.</p>

  <h1 id="json-output">JSON OUTPUT</h1>

  <p>Commands that support the JSON output specify their formats as a
  serialized representation of a C++ <code><b>struct</b></code> or an array
  thereof. For example:</p>

  <pre>struct package
{
  string name;
};

struct configuration
{
  uint64_t         id;
  string           path;
  optional&lt;string> name;
  bool             default;
  vector&lt;package>  packages;
};</pre>

  <p>An example of the serialized JSON representation of
  <code><b>struct</b></code> <code><b>configuration</b></code>:</p>

  <pre>{
  "id": 1,
  "path": "/tmp/hello-gcc",
  "name": "gcc",
  "default": true,
  "packages": [
    {
      "name": "hello"
    }
  ]
}</pre>

  <p>This sections provides details on the overall properties of such formats
  and the semantics of the <code><b>struct</b></code> serialization.</p>

  <p>The order of members in a JSON object is fixed as specified in the
  corresponding <code><b>struct</b></code>. While new members may be added in
  the future (and should be ignored by older consumers), the semantics of the
  existing members (including whether the top-level entry is an object or
  array) may not change.</p>

  <p>An object member is required unless its type is
  <code><b>optional&lt;></b></code>, <code><b>bool</b></code>, or
  <code><b>vector&lt;></b></code> (array). For <code><b>bool</b></code>
  members absent means <code><b>false</b></code>. For
  <code><b>vector&lt;></b></code> members absent means empty. An empty
  top-level array is always present.</p>

  <p>For example, the following JSON text is a possible serialization of the
  above <code><b>struct</b></code> <code><b>configuration</b></code>:</p>

  <pre>{
  "id": 1,
  "path": "/tmp/hello-gcc"
}</pre>

  <h1>EXIT STATUS</h1>

  <p>Non-zero exit status is returned in case of an error.</p>

  <h1>ENVIRONMENT</h1>

  <p>The <code><b>HOME</b></code> environment variable is used to determine
  the user's home directory. If it is not set, then
  <code><b>getpwuid(3)</b></code> is used instead. This value is used to
  shorten paths printed in diagnostics by replacing the home directory with
  <code><b>~/</b></code>. It is also made available to
  <code><b>buildfile</b></code>'s as the <code><b>build.home</b></code>
  variable.</p>

  <p>The <code><b>BUILD2_VAR_OVR</b></code> environment variable is used to
  propagate global variable overrides to nested build system driver
  invocations. Its value is a list of global variable assignments separated
  with newlines.</p>

  <p>The <code><b>BUILD2_DEF_OPT</b></code> environment variable is used to
  suppress loading of default options files in nested build system driver
  invocations. Its values are <code><b>false</b></code> or
  <code><b>0</b></code> to suppress and <code><b>true</b></code> or
  <code><b>1</b></code> to load.</p>

  <h1>BUGS</h1>

  <p>Send bug reports to the
  <a href="mailto:users@build2.org">users@build2.org</a> mailing list.</p>

</div>

<div id="footer">
Copyright &#169; 2014-2024 the build2 authors.<br/>
Permission is granted to copy, distribute and/or modify this document under
the terms of the MIT License.
</div>

</body>
</html>
